Samuel Thibault is a French guy like me, but it took years until we met. He tends to keep a low profile, even though he s doing lots of good work that deserves to be mentioned.
He focuses on improving Debian s accessibility and contributes to the Hurd. Who said he s a dreamer?
Checkout his interview to have some news of Wheezy s status on those topics.
Raphael: Who are you?
Samuel: I am 30 years old, and live in Bordeaux, France. During the workday,
I teach Computer Science (Architecture, Networking, Operating Systems, and
Parallel Programming, roughly) at the University of Bordeaux, and conduct
researches in heterogeneous parallel computing. During the evening, I play the
drums and the trombone in various orchestra (harmonic/symphonic/banda/brass).
During the night, I hack on whatever fun things I can find, mainly accessibility
and the Hurd at the moment, but also miscellaneous bits such as the Linux
console support. I am also involved in the development of Aquilenet, an
associative ISP around Bordeaux, and getting involved in the development of the
network infrastructure in Bordeaux. I am not practicing Judo any more, but I
roller-skate to work, and I like hiking in the mountains. I also read quite a
few mangas. Saturday mornings do not exist in my schedule (Sunday mornings do,
it s Brass Band rehearsal
).
Raphael: How did you start contributing to Debian?
Samuel: Bit by bit.
I have been hacking around GNU/Linux since around 1998. I installed my first
Debian system around 2000, as a replacement for my old Mandrake installation
(which after all my tinkering was actually no longer looking like a Mandrake
system any more!). That was Potato at the time, which somebody offered me
through a set of CDs (downloading packages over the Internet was
unthinkable at the time with the old modems). I have been happily reading and
hacking around documentation, source code, etc. provided on them. Contribution
things really started to take off when I went to the ENS Lyon high school in
2001: broadband Internet access in one s own student room! Since sending a
mail was then really free, I started submitting bugs against various packages I
was using. Right after that I started submitting patches along them, and then
patches to other bugs. I did that for a long time actually. I
had very little knowledge of all packaging details at the time, I was just a
happy hacker submitting reports and patches against the upstream source
code.
At ENS Lyon, I met a blind colleague with very similar hacking tastes (of
course we got friends) and he proposed me, for our student project, to work on
a brlnet project (now called brlapi), a client/server protocol that lets
applications render text on braille devices themselves. Along the way, I got
to learn in details how a blind person can use a Unix system and the principles
that should be followed when developing Accessibility. That is how I got
involved in it. We presented our project at JDLL, and the Hurd booth happened to
be next to our table, so I discussed with the Hurd people there about how the
Hurd console could be used through braille. That is how I got into the Hurd
too. From then on, I progressively contributed more and more to the upstream
parts of both accessibility software and the Hurd. And then to the packaging
part of them. Through patches in bug reports first, as usual, as well as
through discussions on the mailing lists. But quickly enough people gave me
commit access so I could just throw the code in. I was also given control over
the Hurd buildds to keep them running.
It was all good at that stage: I could contribute in all the parts I was caring
about. People however started telling me that I should just apply for being
a Debian Developer; both from accessibility and Hurd sides. I had also seen a bunch of my
friends going through the process. I was however a bit scared (or probably
it was just an excuse) by having to manage a gpg key, it seemed like a quite
dangerous tool to me (even if I already had commit access to glibc at the time
anyway ). I eventually applied for DM in 2008 so as to at least be able
to upload some packages to help the little manpower of the Accessibility and
Hurd teams. Henceforth I had already a gpg key, thus no excuse any more. And
having it in the DM keyring was not enough for e.g. signing the hurd-i386 buildd
packages. So I ended up going through NM in 2009, which went very fast, since
I had already been contributing to Debian and learning all the needed stuff for
almost 10 years! I now have around 50 packages in my QA page, and being a
DD is actually useful for my work, to easily push our software to the masses
So to sum it up, the Debian project is very easy to contribute to and open to
new people. It was used during discussions at the GNU Hackers Meeting
2011 as an example of a very open community with public mailing lists and
discussions. The mere fact that anybody can take the initiative of manipulating
the BTS (if not scared by the commands) without having to ask
anybody is an excellent thing to welcome contributions; it is notable tha the GNU project
migrated to the Debbugs BTS. More generally, I don t really
see the DD status as a must, especially now that we have the DM status (which is
still a very good way to drag people into becoming DDs). For instance, I gave a
talk at FOSDEM 2008 about the state of accessibility in Debian. People did not
care whom I was, they cared that there was important stuff going on and somebody
talking about it. More generally, decisions that are made through a vote are
actually very rare. Most of the time, things just happen on the mailing lists or IRC
channels where anybody can join the discussion.
So I would recommend beginners to first use the software, then start reporting
bugs, then start digging in the software to try fix the bugs by oneself,
eventually propose patches, get them reviewed. At some point the submitted
patches will be correct already most of the time. That s when the maintainers
will start getting bored of just applying the patches, and simply provide with
commit access, and voil , one has become a main contributor.
Raphael: You re one of the main contributors to the Debian GNU/Hurd port.
What motivates you in this project?
Samuel: As I mentioned above, I first got real contact with the Hurd from the
accessibility point of view. That initially brought me into the Hurd console,
which uses a flexible design and nice interfaces to interact with it. The Hurd
driver for console accessibility is actually very straightforward, way simpler
than the Windows or Linux drivers. That is what caught me initially. I have
continued working on it for several reasons.
First, the design is really interesting for users. There are many things that
are natural in the Hurd while Linux is still struggling to achieve them, such
as UID isolation, recently mentioned in LWN. What I really like in the Hurd is
that it excels at providing users with the same features as the administrator s.
For instance, I find it annoying that I still can not mount an ISO image that I build
on e.g. ries.debian.org. Linux now has FUSE which is supposed to permit that,
but I have never seen it enabled on an ssh-accessible machine, only on desktop
machines, and usually just because the administrator happens to be the user of
the machine (who could as well just have used sudo ) For me, it is actually
Freedom #0 of Free Software: let the user run programs for any purpose, that
is, combining things together all the possible ways, and not being prevented
from doing some things just because the design does not permit to achieve them
securely. I had the chance to give a Hurd talk to explain that at GHM 2011,
whose main topic was extensibility , I called it
GNU/Hurd AKA Extensibility
from the Ground, because the design
of the Hurd is basically meant for extensibility, and does not care whether
it is done by root or a mere user. All the tools that root uses to build a
GNU/Hurd system can be used by the user to build its own GNU/Hurd environment.
That is guaranteed by the design itself: the libc asks for things not to the
kernel, but to servers (called translators), which can be provided by root,
or by the user. It is interesting to see that it is actually also tried with
varying success in GNU/Linux, through gvfs or Plash. An example of things I
love being able to do is:
$ zgrep foo
~/ftp://cdn.debian.net/debian/dists/sid/main/Contents-*.gz
On my Hurd box, the ~/ftp: directory is indeed actually served by an ftpfs
translator, run under my user uid, which is thus completely harmless to the
system.
Secondly and not the least, the Hurd provides me with interesting yet not too
hard challenges. LWN confirmed several times that the Linux kernel has become
very difficult to significantly contribute to, so it is no real hacking fun
any more. I have notably implemented TLS support in the Hurd and the Xen
and 64bit support in the GNU Mach kernel used by the Hurd. All three were
very interesting to do, but were already done for Linux (at least for all the
architectures which I actually know a bit and own). It happens that both TLS
and Xen hacking experience became actually useful later on: I implemented TLS
in the threading library of our research team, and the Xen port was a quite
interesting line on my CV for getting a postdoc position at XenSource
Lastly, I would say that I am used to lost causes
My work on accessibility
is sometimes a real struggle, so the Hurd is almost a kind of relief. It is
famous for his vapourware reputation anyway, and so it is fun to just try to contribute
to it nevertheless. An interesting thing is that the opinion of people on the Hurd is
often quite extreme, and only rarely neutral. Some will say it is pure
vapourware, while others will say that it is the hope of humanity (yes we do see
those coming to #hurd, and they are not always just trolls!). When I published
a
0.401 version
on 2011 April 1st, the comments of people were very diverse, and some even
went as far as saying that it was horrible of us to make a joke about the
promised software
Raphael: The FTPmasters want to demote the Hurd port to the debian-ports.org
archive if it doesn t manage a stable release with wheezy. We re now at 2 months
of the freeze. How far are you from being releasable ?
Samuel: Of course, I can not speak for the Debian Release team. The current
progress is however encouraging. During Debconf11, Michael Banck and I discussed with a
few Debian Release team members about the kind of goals that should be achieved,
and we are
near completion of
that part. The Debian GNU/Hurd port can almost completely be installed from
the official mirrors, using the standard Debian
Installer. Some patches need some polishing, but others are just waiting for being uploaded
Debian GNU/Hurd can start a graphical desktop and run office tools such as
gnumeric, as well as the iceweasel graphical web browser, KDE applications
thanks to Pino Toscano s care, and GNOME application thanks to Emilio Pozuelo
Monfort s care. Of course, general
textmode hacking with gcc/make/gdb/etc. just works smoothly. Thanks to recent
work on ghc and ada by Svante Signell, the archive coverage has passed 76%.
There was a concern about network board driver support: until recently, the GNU
Mach kernel was indeed still using a glue layer to embed the Linux 2.2 or even
2.0 drivers (!). Finding a network board supported by such drivers had of course
become a real challenge. Thanks to the GSoC work of Zheng Da, the DDE layer
can now be used to embed Linux 2.6.32 drivers in userland translators, which
was recently ACCEPTed into the archive, and thus brings way larger support for
network boards. It also pushes yet more toward the Hurd design: network drivers
as userland process rather than kernel modules.
That said, the freeze itself is not the final deadline. Actually, freeze
periods are rests for porters, because maintainers stop bringing newer upstream
versions which of course break on peculiar architectures. That will probably be
helpful to continue improving the archive coverage.
Raphael: The kfreebsd port brought into light all the packages which were not
portable between different kernels. Did that help the Hurd port or are the problems
too different to expect any mutual benefit?
Samuel: The two ports have clearly helped each other in many aspects. The
hurd-i386 port is the only non-Linux one that has been kept working (at least
basically) for the past decade. That helped to make sure that all tools
(dpkg, apt, toolchain, etc.) were able to cope with non-Linux ports, and keep
that odd-but-why-not goal around, and evidently-enough achievable. In return,
the kFreeBSD port managed to show that it was actually releasable, at least
as a technological preview, thus making an example. In the daily work, we
have sometimes worked hand in hand. The recent porting efforts of the Debian
Installer happened roughly at the same time. When fixing some piece of code
for one, the switch-case would be left for the other. When some code could
be reused by the other, a mail would be sent to advise doing so, etc. In the
packaging effort, it also made a lot of difference that a non-Linux port is
exposed as released architecture: people attempted by themselves to fix code
that is Linuxish for no real reason.
The presence of the kFreeBSD is however also sometimes a difficulty for the
Hurd: in the discussions, it sometimes tends to become a target to be reached,
even if the systems are not really comparable. I do not need to detail the long
history of the FreeBSD kernel and the amount of people hacking on it, some of
them full-time, while the Hurd has only a small handful of free-time hackers.
The FreeBSD kernel stability has already seen long-term polishing, and a
fair amount of the Debian software was actually already ported to the FreeBSD
kernel, thanks to the big existing pure-FreeBSD hackerbase. These do not hold
for the GNU/Hurd port, so the expectations should go along.
Raphael: You re also very much involved in the
Debian Accessibility team. What
are the responsibilities of this team and what are you doing
there?
Samuel: As you would expect it, the Debian Accessibility team works on packaging
accessibility-related packages, and helping users with them; I thus do both. But
the goal is way beyond just that. Actual accessibility requires
integration.
Ideally enough, a blind user should be able to just come to a Debian desktop
system, plug his braille device, or press a shortcut to enable speech synthesis,
and just use the damn computer, without having to ask the administrator to
install some oddly-named package and whatnot. Just like any sighted user
would do. He should be able to diagnose why his system does not boot, and at
worse be able to reinstall his computer all by himself (typically at 2am ).
And that is hard to achieve, because it means discussing about integration
by default of accessibility features. For instance, the Debian CD
images now beep during at the boot menu. That is a precious feature that
has been discussed between debian-boot and debian-accessibility
for a few weeks before agreeing on how to do it without too much disturbance.
Similarly, my proposition of installing the desktop accessibility engines
has been discussed for some time before being commited. What was however
surprisingly great is that when somebody brought the topic back for discussion,
non-debian-accessibility people answered themselves. This is reassuring,
because it means things can be done durably in Debian.
On the installation side, our current status is that the stable Debian
installer has a high contrast color theme, and several years ago, I have pushed
toward making standard CD images automatically detect braille devices, which
permits standalone installation. I have added to the Wheezy installer some
software speech synthesis (which again brought discussion about size increase vs
versatility etc.) for blind people who do not have a braille device.
I find it interesting to work on such topic in Debian rather than another
distribution, because Debian is an upstream for a lot of distributions.
Hopefully they just inherit our accessibility work. It at least worked for the
text installer of Ubuntu.
Of course, the Accessibility team is looking for help, to maintain
our current packages, but also introduce new packages from the
TODO list or create
some backports. One does not need to be an expert in accessibility: tools can
usually be tested, at least basically, by anybody, without particular hardware
(I do not own any, I contributed virtual ones to qemu). For new
developments and ideas, it is strongly recommended to come and discuss on
debian-accessibility, because it is easy to get on a wrong track that does not
bring actual accessibility.
We still have several goals to achieve: the closest one is to just fix the
transition to gnome3, which has been quite bad for accessibility so far :/
On the longer run, we should ideally reach the scenario I have detailed above:
desktop accessibility available and ready to be enabled easily
by default.
Raphael: What s the biggest problem of Debian?
Samuel: Debian is famous for its heated debian-devel discussions. And some
people eventually say this no fun any more . That is exemplified in a less
extreme way in the debian-boot/accessibility discussions that I have mentioned
above. Sometimes, one needs to have a real stubborn thick head to continue
the discussion until finding a compromise that will be accepted for commit.
That is a problem because people do not necessarily have so much patience, and will
thus prefer to contribute to a project with easier acceptance. But it is also
a quality: as I explained above, once it is there, it is apparently for good.
The Ubuntu support of accessibility in its installer has been very diverse, in
part due to quite changing codebase. The Debian Installer codebase is more in a
convergence process. Its base will have almost not changed between squeeze and
wheezy. That allowed the Debian Accessibility team to continue improving its
accessibility support, and not have to re-do it. A wiki page explains how to
test its accessibility features, and some non-debian-accessibility people do go
through it.
A problem I am much more frightened by is the manpower in some core teams. The
Debian Installer, grub, glibc, Xorg, gcc, mozilla derivatives, When reading
the changelogs of these, we essentially keep seeing the same very few names over
and over. And when one core developer leaves, it is very often still the same
names which appear again to do the work. It is hard to believe that there are
a thousand DDs working on Debian. I fear that Debian does not manage to get
people to work on core things. I often hear people saying that they do not even
dare thinking about putting their hands inside Xorg, for instance. Xorg is
complex, but it seems to me that it tends to be overrated, and a lot of people
could actually help there, as well as all the teams mentioned above. And if nobody
does it, who will?
Raphael: Do you have wishes for Debian Wheezy?
Samuel: That is an easy one
Of course I wish that we manage to release the
hurd-i386 port. I also wish that accessibility of gnome3 gets fixed enough
to become usable again. The current state is worrying: so much has changed
that the transition will be difficult for users already, the current bugs will
clearly not help. I also hope to find the time to fix the qt-at-spi bridge,
which should (at last!) bring complete KDE accessibility.
Raphael: Is there someone in Debian that you admire for their
contributions?
Samuel: Given the concerns I expressed above, I admire all the people who do
spend time on core packages, even when that is really not fun everyday. Just
to alphabetically name a few people I have seen so often here and there in the
areas I have touched in the last few years: Aur lien Jarno, Bastian
Blank, Christian Perrier, Colin Watson, Cyril Brulebois, Frans Pop, J rg
Jaspert, Joey Hess, Josselin Mouette, Julien Cristau, Matthias Klose, Mike
Hommey, Otavio Salvador, Petr Salinger, Robert Millan, Steve Langasek. Man, so
many things that each of them works on! Of course this list is biased towards the parts that I touched, but people working in others core areas also deserve the same admiration.
Thank you to Samuel for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that older interviews are indexed on
wiki.debian.org/PeopleBehindDebian.
Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook.
3 comments Liked this article? Click here. My blog is Flattr-enabled.
With 
I *did* some hacking at DebConf, as usual. For once, I had no TODO
list: after all, I never complete these, so why make one?
Still, I participated to discussions around samba packaging, mostly
animated by Ivo De Decker and I think we're making good progress
towards samba 4.x packages. The road is long, quite complicated, but
we now have a stronger team, with a very active Ivo, Jeroen Dekkers
who officially joined, Steve Langasek who still cherishes one of his
pet packages (and even branched in our git with the Ubuntu packages).
Great work and thanks to Ivo for pushing this forward.
I also worked quite actively on the migration of fonts packages to git
(I now reached the point where I'm more comfortable with git than SVN,
yes, everything can happen). These packages were modernized at the
same time and checked for new upstream versions (I have to say that
few of these fonts had new upstream versions, indeed). We
unfortunately found no time to have a good font BoF in Vaumarcus,
indeed...but I'm not sure we would have many things to say. The work
is done and done well, in this team.
Some progress was made, also, for restoring a working "monolithic"
build of D-I. This build gathers together all udebs from unstable,
which means it offers a D-I image that uses ALL udebs from
nustable.....which is not the default of other images. This would be
very helpful for translators who want to check their work as soon as
possible. In the future, with a Jenkins task that would build each
package at each commit and then build a monolithic image, we could
have a way to provide a tes snapshot of D-I git repos.....which could
help catching more bugs (or more of my stupid mistakes).
So, in general, I consider this a quite successful DebConf when it
comes at "real" production.
So 
This is my monthly summary of my free software related activities. If you re among the people who 
I've managed to go for eleven years working on Debian and nearly eight on Ubuntu without ever needing to teach myself how APT's resolver works. I get the impression that there's a certain mystique about it in general (alternatively, I'm just the last person to figure this out). Recently, though, I had a couple of Ubuntu upgrade bugs to fix that turned out to be bugs in the resolver, and I thought it might be interesting to walk through the process of fixing them based on the 
good news: from looking through RC bugs in the